Introduction to Requirements
Concepts
- Requirements
- Requirements Management
- Types of Requirements
- Traceability
- User-Centered Design
- Use-Case View
Purpose 
The purpose of the Requirements workflow is:
- To establish and maintain agreement with the customers and other stakeholders on what the system should do.
- To provide system developers with a better understanding of the system requirements.
- To define the boundaries of (delimit) the system.
- To provide a basis for planning the technical contents of iterations.
- To provide a basis for estimating cost and time to develop the system.
- To define a user-interface for the system, focusing on the needs and goals of the users.
To achieve these goals, it is important, first of all, to understand the definition and scope of the problem which we are trying to solve with this system. The Business Rules, Business Use-Case Model and Business Object Model developed during Business Modeling will serve as valuable input to this effort. Stakeholders are identified and Stakeholder Requests are elicited, gathered and analyzed.
A Vision document, a use-case model, use cases and Supplementary Specification are developed to fully describe the system - what the system will do - in an effort that views all stakeholders, including customers and potential users, as important sources of information (in addition to system requirements).
Stakeholder Requests are both actively elicited and gathered from existing sources to get a "wish list" of what different stakeholders of the project (customers, users, product champions) expect or desire the system to include, together with information on how each request has been considered by the project.
The Vision document provides a
complete vision for the software system under development and supports the
contract between the funding authority and the development organization.
Every project needs a source for capturing the expectations among
stakeholders. The vision document
is written from the customers' perspective, focusing on the essential features
of the system and acceptable levels of quality.
The Vision should include a description of what features
will be included as well
as those considered but not included.
It should also specify operational capacities (volumes, response times,
accuracies), user profiles, and interoperational interfaces with entities
outside the system boundary, where applicable. The Vision document provides the
contractual basis for the requirements visible to the stakeholders.
The use-case model should serve as a communication medium and can serve as a contract between the customer, the users, and the system developers on the functionality of the system, which allows:
- Customers and users to validate that the system will become what they expected.
- System developers to build what is expected.
The use-case model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors, and what the system does in the use case. Use cases function as a unifying thread throughout the software lifecycle; the same use-case model is used in system analysis, design, implementation, and testing.
The Supplementary Specifications are an important complement to the use-case model, because together they capture all software requirements (functional and nonfunctional) that need to be described to serve as a complete software requirements specification.
A complete definition of the software requirements described in the use cases and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.
Complementary to the above mentioned artifacts, the following artifacts are also developed:
The Glossary is important because it defines a common terminology which is used consistently across the project or organization.
The Use-Case Storyboard and User-Interface Prototype are all results of user-interface modeling and prototyping, which are done in parallel with other requirements activities. These artifacts provide important feedback mechanisms in later iterations for discovering unknown or unclear requirements.
Relation to Other Workflows
The Requirements workflow is related to other process workflows.
- The Business Modeling workflow provides Business Rules, a Business Use-Case Model and a Business Object Model, including a Domain Model and an organizational context for the system.
- The Analysis & Design workflow gets its primary input (the use-case model and the Glossary) from Requirements. Flaws in the use-case model can be discovered during analysis & design; change requests are then generated, and applied to the use-case model.
- The Test workflow tests the system to verify the code against the Use-Case Model. Use Cases and Supplementary Specifications provide input on requirements used in planning and designing tests.
- The Environment workflow, develops and maintains the supporting artifacts that are used during requirements management and use-case modeling, such as the Use-Case-Modeling Guidelines and User-Interface Guidelines.
- The Management workflow plans the project, develops the Requirements Management Plan, and each iteration (described in an Iteration Plan). The use-case model is an important input to the iteration planning activities.
